1. Field of the Invention
This invention pertains generally to computer systems, and more particularly to methods and techniques for monitoring, testing and controlling the operation of one or more computers through communications links.
2. Description of the Related Art
With the early development of computers, all processing capability was located at a single computer system. These early machines were massive structures using many vacuum tubes, the result of which was the generation of an enormous amount of heat, and an associated sensitivity to environment. With these massive structures, all processing was performed centrally at this main computer, owing to the substantial expense required for isolation and environmental control. While remote communications with a computer system were sometimes used, the use was extremely infrequent and necessarily limited owing to the poor communications capability available at the time. These limitations of the need for environmental control and lack of adequate communications capability each persisted for several decades.
Progress in the semiconductor industry, initially with compact calculators beginning shortly after 1970 and followed by much more concentrated and capable chips suitable for computers less than a decade later, diminished and has ultimately virtually eliminated the need for extensive environmental control. Likewise, communications equipment, protocols and bandwidth compression have opened up the ability for substantial remote communications that were inconceivable only a few years ago.
For years, essentially from the days of first deployment of desktop computing, when a problem was encountered with a system, a computer user would be forced to resort to verbal telephone support with the hardware manufacturer. The waiting queues for these technical support personnel were notoriously long, with on-hold waits longer than an hour commonplace. When the technical support personnel were contacted, then the user would have to work verbally with the technical support person, and the support personnel would have to rely upon the computer users accurately describing the status and events, and performing operations requested by the support personnel. This arrangement was clearly less than optimum, requiring many times the effort that would have been required for the support personnel or a technician to directly diagnose and resolve the problem. Nevertheless, heretofore there has been little available for rapidly diagnosing the source of problems.
Unfortunately, many of the same issues and challenges face software vendors as those outlined above with regard to hardware manufacturers. When a particular program is prepared, the preparation work is usually performed upon a single type of computer having a particular combination of software installed thereon. All too frequently, the code will unintentionally rely upon components or features, such as may be found in the operating system, BIOS, system components or the like, which may vary from computer to computer. These variations may be based upon the release date of the particular computer, the software available at that time, upgrades provided by other vendors at the time of installation of their software, and other factors. At the time of deployment of early versions of the software, commonly referred to as alpha or beta versions, many of the incompatibility issues with diverse computers are discovered. Unfortunately, heretofore there has been no efficient way to diagnose the incompatibility, nor to quickly test the computer or isolate the source of the problem. Help databases have been prepared where persons may look for similar problems. Nevertheless, the amount of time involved in isolating and diagnosing a problem is still enormous and a source of much waste in the industry.
Even during the development of the software, substantial testing must be done. As is known in the art of programming, while a change in one part of the source code may not be expected to have an effect elsewhere, all too frequently this expectation is incorrect. As a result, even the most minor changes require substantial testing and validation to ensure that the changes do not disrupt the performance of a program at any other point. Presently, many software companies employ persons specifically in the role of testing. These persons will be assigned the chore of interacting with the computer as though they were a regular user, trying out each of the functions and determining whether any bugs may be identified. This approach also requires substantial operation by testing personnel, and is somewhat unreliable owing to the difficulty in determining whether the testers are, in fact, completing the testing properly and thoroughly. Nevertheless, this approach still provides cost saving over discovering a problem in the field after the software or hardware has been released more generally. Furthermore, the reputation of the company is improved by having fewer problems with the released software or hardware than competitors who utilize less thorough testing.
In the area of system administration, similar problems are also encountered. An IT professional will typically be called upon to implement a new program, upgrade or other such tasks throughout an entire network or system. In such instance, the administrator will frequently be required to visit each and every computer in order to perform the necessary tasks, and to verify the proper functioning thereof. This opportunity to access the computers has been made far more difficult with the advent of mobile systems and wireless communications, where many more of the computers connected through the network are not physically accessible at any given time.
In order to verify the performance of either software, hardware or a combination of the two, and regardless of whether the verification is being driven from the perspective of a manufacturer, developer, vendor, technical support, or internal maintenance within a single organization, this verification requires substantial interaction with the computer.
In an attempt to reduce the overhead associated with software debugging, a number of persons have developed methods for testing software by using a computer program. Many of these methods send information directly to the software or hardware, thereby bypassing the normal input channels and operations. Representative of the computer testing methods are U.S. Pat. No. 5,371,883 to Gross et al; U.S. Pat. No. 6,046,740 to LaRoche et al; U.S. Pat. No. 6,026,236 to Fortin et al; U.S. Pat. No. 5,022,028 to Edmonds et al; U.S. Pat. No. 5,249,270 to Stewart et al; U.S. Pat. Nos. 5,321,838 and 5,333,302 to Hensley et al; U.S. Pat. No. 5,335,342 to Pope et al; U.S. Pat. No. 5,594,892 to Bonne et al; U.S. Pat. No. 5,881,230 to Christensen et al; U.S. Pat. No. 5,926,638 to Inoue; U.S. Pat. No. 5,669,000 to Jessen et al; U.S. Pat. No. 6,119,247 to House et al; U.S. Pat. No. 6,195,765 to Kislanko et al; U.S. Pat. No. 6,249,882 to Testardi; U.S. Pat. No. 6,282,701 to Wygodny et al; and U.S. Pat. No. 6,353,897 to Nock et al; and 2002/0,099,978 to Kraffert, the contents of each which are incorporated herein for their teachings of the various methods and techniques associated with the control and operations associated with such systems. Nevertheless, no high level methods are introduced which readily permit the operator to perform the desired tests and operations on remote computers, particularly while interacting through the same or similar input devices and channels as would occur with standard human operations.